Subject: 40th IETF-WASHINGTON: QOSR

From: HJ Sandick <[email-masked]>
Date: Thu, 30 Oct 1997 09:31:59 -0500

QOSR has one meeting slot at the Washington IETF:

        Thursday, December 11 at 0900-1130 AM.

Please send agenda items to Eric and myself.  There is a limited amount of
space.

Regards,

Hal

Hal Sandick
IBM, NHD
(919) 254-4614
sandickh@rtp (internal ibm)
[email-masked] (external)

---

From: Bala Rajagopalan <[email-masked]>
Date: Thu, 30 Oct 1997 14:36:29 -0500

> Please send agenda items to Eric and myself.  There is a limited amount of

I suggest that presentations be invited 
on the larger issues, especially from ISPs:

- what sort of QoSR capabilities are needed 

- what should be the next step in the development of
QoSR in the IETF

- deployment scenarios

- enterprise vs backbone issues with regard to QoSR

- unicast and multicast: whether the focus should be on 
unicast exclusively for the time being

I think this is more useful at this stage than presentations
on specific protocol aspects. I welcome any additions to
this list, as well as a discussion of these issues in this
list prior to the December meeting.

Best Regards,
-- 

Bala Rajagopalan
NEC USA, C&C Research Labs
4 Independence Way
Princeton, NJ 08540
U.S.A

Ph: +1-609-951-2969
Fax: +1-609-951-2499
Email: [email-masked]

---

From: Roch Guerin <[email-masked]>
Date: Thu, 30 Oct 97 15:26:14 -0500

>on the larger issues, especially from ISPs:

I think this is indeed a very good idea and I second it
wholeheartedly.   Roch

---

From: Masataka Ohta <[email-masked]>
Date: Fri, 31 Oct 97 13:22:20 JST

Bala;

> on the larger issues,

A good idea.

I'd like to make a presentation on why inter- and intra- domain
separation is harmful.

I can also make a presentation on how RSVP (assuming RSVP is used
for QoS) MUST be modified.

> especially from ISPs:

Even though most ISPs are not offering even plain RSVP service?

At this early stage with no experience on QoSR, I think discussion
should be focused on the larger issues of "what we theoretically
can't do".

> - what sort of QoSR capabilities are needed 

We first need to agree on terminologies.

> - what should be the next step in the development of

Have a framework document based on the discussion on the larger issues.

> - deployment scenarios

Deployment of what? A particular algorithm has its own deployment senario.

It's foolish to determin the deployment scenarios at this stage only
to limit our selection of algorithms.

> - enterprise vs backbone issues with regard to QoSR

It seems to me that the discussion, then, is too much detailed.

> unicast exclusively for the time being

It's not a policy issue.

The question is purely technical that:

	whether QoSR can support multicast or not.

If we can, there is no reason not to do so.

If we can't, it is a serious problem for QoSR WG.

As you might know, people like Steve Deering believe that QoSR no good.

						Masataka Ohta